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Типичный Enterprise 


Стоимость оборудования 1-5 млрд. USD 


Количество поддержки 300-1500 инженеров поддержки и 
технических контактов в приложениях 


Стоимость функционирования 150-500 млн. USD / год 


Типичный Enterprise - история 


e 50—100 лет истории бизнеса и 40+ лет ИТ 


e Использование всех технологий когда-либо 
существовавших 

e IBM 360, мейнфреймы, AS/400, АХ, HPUX, 
Sparc/Solaris... 

e Kobol, C/C++ 20-летней давности... 


Типичный Enterprise - история 


e Ключевой фактор инфраструктуры — надежность 


• Типичный дизайн — пара дата-центров: 
e В основном ДЦ — active/passive НА 
e Во вспомогательном ДЦ — ОК, тестовые и 
разработческие среды 
e Многократное дублирование сетевых устройств 


Типичный Enterprise - история 


• Ключевой фактор разработки — быстрая реализация 
бизнес-задач 


e И даже разработка отдельных платформ для 
конкретных трейдеров/групп или продуктов 


e Почему — только новые продукты приносят деньги. 
Как только продукт появляется у конкурентов, цена 
падает до порога прибыльности 


use only 


Типичный Enterprise – последствия 


• 40 лет гонки за бизнес-задачами породили колоссальную 
сложность управления софтом и инфраструктурой 


г Оптимизацией с точки зрения стоимости владения никто 
не занимался 


e Оптимизацией с точки зрения стоимости инфраструктуры 
никто не занимался 
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Типичный Enterprise – последствия 


Сложность достигла такого уровня, что стоимость 
владения начала существенно влиять на стоимость 
ведения бизнеса, даже с учетом достаточной 
прибыльности инвестиционных банков 


Колоссальная инертность — «40 лет всё было хорошо, 
почему проблемы возникли сейчас?» 
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Типичный Enterprise - последствия 


° Средняя загрузка CPU 5-15% 
' Средняя загрузка сети 1-5-10% 
` Двадцать дата-центров полностью забиты оборудованием 


Как следствие: 


Очень длинное время доставки Очень много старого 
оборудования оборудования 
Сложная 3-4 уровневая топология сети Проблемы с расширяемостью 


Плохая скорость сети Плохая скорость систем хранения 


Типичный Enterprise - последствия 


Только когда проблемы ИТ стали серьезно мешать 
бизнесу, бизнес принял решение о трансформации ИТ 
и стал интересоваться, что и как можно улучшить 


Вот так могу 


Приложений <100 


Стоимость 1-5 млрд. USD 0.25 млрд. USD 
оборудования 


Количество 300-1500 инженеров 30 инженеров 
поддержки 


Run cost 150-500M USD / roa 50M USD/ год 
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Oak Ridge Supercomputer Center 
(суперкомпьютер Summit) 


30 инженеров — никакой сложности поддержки 
Нет диверсификации оборудования 

Малая полная стоимость оборудования 

Малое количество единиц оборудования 

Нет проблем с расширением 

Гипер-скоростная и простая сеть 


Гипер-скоростная система хранения 
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Что дает НРС-оборудование - сеть 
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Mellanox CS8500 


800 портов no 200Гб/сек 

320 Тб/сек полная скорость переключений 
1-2х уровневая сеть 

130нс латентность 


Что дает НРС-оборудование - хранение 


Supermicro МММе-стойка 


672М операции в секунду 
840GB/s пропускная способность 
10.7 РВ емкость (8ТВ NVMe SSD) 


Что дает НРС-оборудование - сервера 


Atos BullSequana XH2000 


32 лезвия 

3 сервера на лезвие 

В стойке: 

410 20 Blades 12288 ядер (Epyc 64 ядра) 

prre tonon 196 ТБ памяти (128GB модуль) 
19.2T6/sec пропускной способности сети 


Как использовать НРС-оборудование в 
Enterprise/Highload? 


Лучше писать Software © 


Как лучше писать Software? 


Отрицание 
Гнев 
Торг 

Депрессия 

Принятие 


Микросервисы в НРС-стиле 


Площадь ячейки равна объему работы 


Микросервисы 


Микросервисы в НРС-стиле 


Площадь ячейки равна объему работы 


Автоматическое Разделение процессов сохранения 
масштабирование данных и обработки 
Асинхронность & пакетная Низко-латентные высоко- 
обработка скоростные протоколы (UDP) 


Фреймворки контроля бизнес/технических показателей и среды 


Полный мониторинг платформ 
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Автоматическое масштабирование 


Масштабирование — увеличение/уменьшение количества 
реплик/инстансов в зависимости от: 


1. Простой вариант — в зависимости от загрузки СРО/памяти/сети 


. Сложный - в зависимости от бизнес-процессов 
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Разделение процессов сохранения данных 
и обработки 


` Быстрые операции обработки данных в памяти не должны 
упираться в конце в ожидание записи в базу данных или другое 
персистентное хранилише 


Варианты: 
1. Запись результатов в распределенный кэш 


2. Оправка сообщением 


Асинхронность & пакетная обработка 


Количество операций в распределенных системах ограничено 
задержками. 


При задержках 1мс, возможно только 1000 операций в секунду 


Правило: 


Одна операция должна работать с десятками и сотнями объектов, 
а не с одним объектом — асинхронность с клиентом + пакетная 
обработка 


Низко-латентные высоко-скоростные 
протоколы (UDP) 
Протоколы с подтверждением в сети IB не нужны 


Приоритет — нано-секундная латентность 


Варианты библиотек UDP-npotokona: 
1. smUDP (Одноклассники) 


2. Aeron (Martin Thompson) 


Фреймворки контроля бизнес/технических 
показателей и среды 


Борьба с перегрузками и OOM 


. Ограничение количества запросов 
. Ограничение по использованию памяти/цпу 


. Проверки связности с другими сервисами (trottling) 


Полный мониторинг платформ 


| Мониторинг индивидуальных инстансов 


` Мониторинг внутренних параметров (GC, сри usage/ram 
usage/thread usage/ времена get/put Ha map/queue/list/set) 


· Мониторинг бизнес-показателей (операций в 
секунду/продолжительность операций) 


° Забудьте о логах – только метрики в Prometheus 


· Логи только для неструктурированных ошибок 


Что же получим в результате? 


60 миллиардов запросов за 44 часа — Гугл на обычном железе 
Task stats 


Task status counters 


9/7 00:00 9/7 04:00 9/7 08:00 9/7 12:00 9/7 16:00 9/7 20:00 9/8 00:00 9/8 04:00 9/8 08:00 9/8 12:00 9/8 16:00 9/8 20:00 


COMPLETED - NEW PENDING = REGISTERED == REMOVED 
RUNNING 


Мониторинг низкоуровневых операций 


Ignite internal cache gets per second 


5.0K ops 


16:35 16:40 16:45 16:50 16:55 


datastore-20-2kb54 - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current: 


datastore-20-48mbhv - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current 
= datastore-20-95rpd - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current 
datastore-20-9n87r - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current 


Ignite internal cache puts per second 


16:35 16:40 16:45 16:50 16:55 


datastore-20-2kb54 - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current 


datastore-20-48mbv - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current: 
= datastore-20-95rpd - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current: 
datastore-20-9n87r - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current 


Ignite internal cache removals per second 


4.0K ops 


2.0K ops 


1.0K ops 


16:35 16:40 16:45 16:50 16:55 


datastore-20-2kb54 - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current: 


datastore-20-48mhv - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current 
= datastore-20-95rpd - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current 
datastore-20-9n87r - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current 
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Ignite internal cache invocations per second ~ 


200 ops 


16:35 16:40 16:45 16:50 16:55 


datastore-20-2kb54 - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current: 


datastore-20-48mbv - datastructures_ATOMIC_PARTITIONED_1@default-ds-group 
Current 
= datastore-20-95rpd - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current: 
datastore-20-9n87r - datastructures_ATOMIC_PARTITIONED_1 @default-ds-group 
Current 


Мониторинг асинхронности (thread pool) 


Здесь будет слайд с 85К распределенных операций в 
секунды, как безопасники согласуют 
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